对 Windows Server 软件定义的网络堆栈进行故障排除

本指南介绍常见的软件定义网络 (SDN) 错误和故障方案,并概述了使用可用诊断工具的故障排除工作流。 有关 SDN 的详细信息,请参阅 软件定义的网络

适用于:Windows Server 2022、Windows Server 2019、Windows Server 2016、Azure Stack HCI 版本 21H2 和 20H2

错误类型

以下列表表示 Hyper-V 网络虚拟化 (HNVv1) 在 Windows Server 2012 R2 中从市场内生产部署中最常遇到的问题类别,并且在许多方面与 Windows Server 2016 HNVv2 中的相同类型问题与新的软件定义的网络 (SDN) Stack 中遇到的相同类型的问题一致。

大多数错误可分为一小组类:

  • 配置无效或不受支持

    用户调用 NorthBound API 不正确或策略无效。

  • 策略应用程序中的错误

    例如,在实时迁移) 之后,网络控制器的策略未传递到 Hyper-V 主机、延迟或不是所有 Hyper-V 主机上 (。

  • 配置偏移或软件 bug

    导致丢弃数据包的数据路径问题。

  • 与 NIC 硬件/驱动程序或底层网络结构相关的外部错误

    执行错误任务会卸载 ((例如 VMQ) 或底层网络结构配置错误 (,例如 MTU)

    本故障排除指南将检查每个错误类别,并推荐可用于识别和修复错误的最佳做法和诊断工具。

诊断工具

在讨论每种错误类型的故障排除工作流之前,让我们先看看可用的诊断工具。

若要使用网络控制器 (控制路径) 诊断工具,必须先安装 RSAT-NetworkController 该功能并导入模块 NetworkControllerDiagnostics

Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools
Import-Module NetworkControllerDiagnostics

若要使用 HNV 诊断 (数据路径) 诊断工具,必须导入模块 HNVDiagnostics

# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics

网络控制器诊断

这些 cmdlet 记录在 TechNet 上的 网络控制器诊断 cmdlet 中。 它们有助于识别网络控制器节点之间以及网络控制器与 Hyper-V 主机上运行的 NC 主机代理之间的控制路径中的网络策略一致性问题。

Debug-ServiceFabricNodeStatusGet-NetworkControllerReplica cmdlet 必须从其中一个网络控制器节点虚拟机运行。 所有其他 NC 诊断 cmdlet 都可以从任何主机运行,该主机已连接到网络控制器,并且位于 Kerberos) (网络控制器管理安全组中,或者有权访问用于管理网络控制器的 X.509 证书。

Hyper-V 主机诊断

Hyper-V 网络虚拟化 (HNV) 诊断 cmdlet 中介绍了这些 cmdlet。 它们可帮助识别租户虚拟机 (东/西) 和通过 SLB VIP (北/南) 的入口流量之间的数据路径问题。

Debug-VirtualMachineQueueOperationGet-CustomerRoute、、Get-PACAMappingGet-ProviderAddressGet-VMNetworkAdapterPortIdGet-VMSwitchExternalPortIdTest-EncapOverheadSettings 都是可从任何 Hyper-V 主机运行的本地测试。 其他 cmdlet 通过网络控制器调用数据路径测试,因此需要如上所述访问网络控制器。

GitHub

Microsoft/SDN GitHub 存储库具有许多基于这些内置 cmdlet 构建的示例脚本和工作流。 具体而言,可以在“诊断”文件夹中找到 诊断 脚本。 通过提交拉取请求来帮助我们参与这些脚本。

排查工作流和指南问题

[Hoster]验证系统运行状况

在多个网络控制器资源中,有一个名为 Configuration State 的嵌入式资源。 配置状态提供有关系统运行状况的信息,包括网络控制器的配置与 Hyper-V 主机上运行) 状态的实际 (之间的一致性。

若要检查配置状态,请从连接到网络控制器的任何 Hyper-V 主机运行以下命令。

注意

参数的值 NetworkController 应是基于为网络控制器创建的 X.509 >证书的使用者名称的 FQDN 或 IP 地址。

Credential仅当网络控制器使用 kerberos 身份验证 (VMM 部署) 中的典型情况时,才需要指定 参数。 凭据必须为网络控制器管理安全组中的用户。

Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP> [-Credential <PS Credential>]

# Healthy State Example - no status reported
$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController 10.127.132.211 -Credential $cred

Fetching ResourceType:     accessControlLists
Fetching ResourceType:     servers
Fetching ResourceType:     virtualNetworks
Fetching ResourceType:     networkInterfaces
Fetching ResourceType:     virtualGateways
Fetching ResourceType:     loadbalancerMuxes
Fetching ResourceType:     Gateways

配置状态消息示例如下所示:

Fetching ResourceType:     servers
---------------------------------------------------------------------------------------------------------
ResourcePath:     https://10.127.132.211/Networking/v1/servers/4c4c4544-0056-4b10-8058-b8c04f395931
Status:           Warning

Source:           SoftwareLoadBalancerManager
Code:             HostNotConnectedToController
Message:          Host is not Connected.
----------------------------------------------------------------------------------------------------------

注意

系统中存在一个 bug,其中 SLB 复用传输 VM NIC 的网络接口资源处于失败状态,出现错误“虚拟交换机 - 主机未连接到控制器”。 如果 VM NIC 资源中的 IP 配置设置为传输逻辑网络 IP 池中的 IP 地址,则可以安全地忽略此错误。

系统中存在另一个 bug,其中网关 HNV 提供程序 VM NIC 的网络接口资源处于失败状态,并出现错误“虚拟交换机 - 端口阻止”。 如果根据设计) ,VM NIC 资源中的 IP 配置设置为 null (,也可以安全地忽略此错误。

下表显示了要根据观察到的配置状态执行的错误代码、消息和后续操作的列表。

代码 邮件 操作
未知 未知错误
HostUnreachable 无法访问主机 检查网络控制器和主机之间的管理网络连接
PAIpAddressExhausted PA IP 地址已用尽 增加 HNV 提供程序逻辑子网的 IP 池大小
PAMacAddressExhausted PA Mac 地址用尽 增加 Mac 池范围
PAAddressConfigurationFailure 无法将 PA 地址管道传递给主机 检查网络控制器和主机之间的管理网络连接。
CertificateNotTrusted 证书不受信任 修复用于与主机通信的证书。
CertificateNotAuthorized 证书未授权 修复用于与主机通信的证书。
PolicyConfigurationFailureOnVfp 配置 VFP 策略失败 这是运行时故障。 没有明确的解决方法。 收集日志。
PolicyConfigurationFailure 由于通信失败或 NetworkController 中出现其他错误,无法将策略推送到主机。 没有明确的操作。 这是由于网络控制器模块中目标状态处理失败造成的。 收集日志。
HostNotConnectedToController 主机尚未连接到网络控制器 端口配置文件未应用于主机或主机无法从网络控制器访问。 验证 HostID 注册表项是否与服务器资源的实例 ID 匹配
MultipleVfpEnabledSwitches 主机上有多个启用了 VFp 的交换机 删除其中一个交换机,因为网络控制器主机代理仅支持一个启用了 VFP 扩展的 vSwitch
PolicyConfigurationFailure 由于证书错误或连接错误,无法为 VmNic 推送 VNet 策略 检查是否已部署正确的证书 (证书使用者名称必须与主机) 的 FQDN 匹配。 同时验证主机与网络控制器的连接
PolicyConfigurationFailure 由于证书错误或连接错误,无法为 VmNic 推送 vSwitch 策略 检查是否已部署正确的证书 (证书使用者名称必须与主机) 的 FQDN 匹配。 同时验证主机与网络控制器的连接
PolicyConfigurationFailure 由于证书错误或连接错误,无法推送 VmNic 的防火墙策略 检查是否已部署正确的证书 (证书使用者名称必须与主机) 的 FQDN 匹配。 同时验证主机与网络控制器的连接
DistributedRouterConfigurationFailure 未能在主机 vNic 上配置分布式路由器设置 TCPIP 堆栈错误。 可能需要清理报告此错误的服务器上的 PA 和 DR 主机 vNIC
DhcpAddressAllocationFailure VMNic 的 DHCP 地址分配失败 检查是否在 NIC 资源上配置了静态 IP 地址属性
CertificateNotTrusted
CertificateNotAuthorized
由于网络或证书错误,无法连接到 Mux 检查错误消息代码中提供的数字代码:这对应于 winsock 错误代码。 证书错误是精细 (例如,证书无法验证、证书未授权等 )
HostUnreachable MUX 运行不正常 (常见情况是 BGPRouter 断开连接) RRAS (BGP 虚拟机上的 BGP 对等) 或架顶 (ToR) 交换机无法访问或无法成功对等互连。 检查软件负载均衡器多路复用器资源和 BGP 对等 (ToR 或 RRAS 虚拟机上的 BGP 设置)
HostNotConnectedToController SLB 主机代理未连接 检查 SLB 主机代理服务是否正在运行;请参阅 SLB 主机代理日志 (自动运行) 的原因,如果 SLBM (NC) 拒绝,主机代理提供的证书运行状态将显示细微差别信息
PortBlocked 由于缺少 VNET/ACL 策略,VFP 端口被阻止 检查是否存在可能导致未配置策略的任何其他错误。
重载 负载均衡器 MUX 已重载 MUX 的性能问题
RoutePublicationFailure 负载均衡器 MUX 未连接到 BGP 路由器 检查 MUX 是否与 BGP 路由器建立了连接,以及是否正确设置了 BGP 对等互连
VirtualServerUnreachable 负载均衡器 MUX 未连接到 SLB 管理器 检查 SLBM 和 MUX 之间的连接
QosConfigurationFailure 未能配置 QOS 策略 如果已使用 QOS 预留,则查看是否为所有 VM 提供足够的带宽

检查网络控制器与 Hyper-V 主机 (NC 主机代理服务之间的网络连接)

netstat运行以下命令,验证 NC 主机代理与网络控制器节点之间存在三ESTABLISHED个连接, () ,Hyper-V 主机上有一个LISTENING套接字。

  • 侦听 Hyper-V 主机上的端口 TCP:6640 (NC 主机代理服务)
  • 从端口 6640 上的 Hyper-V 主机 IP 到临时端口上的 NC 节点 IP 的两个已建立连接 (> 32000)
  • 从临时端口上的 Hyper-V 主机 IP 到端口 6640 上的网络控制器 REST IP 建立一个连接

注意

如果未在该特定主机上部署租户虚拟机,则 Hyper-V 主机上可能只有两个已建立的连接。

netstat -anp tcp |findstr 6640

# Successful output
  TCP    0.0.0.0:6640           0.0.0.0:0              LISTENING
  TCP    10.127.132.153:6640    10.127.132.213:50095   ESTABLISHED
  TCP    10.127.132.153:6640    10.127.132.214:62514   ESTABLISHED
  TCP    10.127.132.153:50023   10.127.132.211:6640    ESTABLISHED

检查主机代理服务

网络控制器与 Hyper-V 主机上的两个主机代理服务进行通信:SLB 主机代理和 NC 主机代理。 其中一个或两个服务可能未运行。 检查其状态,如果它们未运行,请重启。

Get-Service SlbHostAgent
Get-Service NcHostAgent

# (Re)start requires -Force flag
Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force

检查网络控制器的运行状况

如果没有三ESTABLISHED个连接或网络控制器显示为无响应,检查使用以下 cmdlet 来查看所有节点和服务模块是否已启动并运行。

# Prints a DIFF state (status is automatically updated if state is changed) of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>

网络控制器服务模块包括:

  • ControllerService
  • ApiService
  • SlbManagerService
  • ServiceInsertion
  • FirewallService
  • VSwitchService
  • GatewayManager
  • FnmService
  • HelperService
  • UpdateService

检查 是否 ReplicaStatusReadyHealthStateOk

在具有多节点网络控制器的生产部署中,还可以检查每个服务的主要节点及其各个副本 (replica) 状态。

Get-NetworkControllerReplica

# Sample Output for the API service module
Replicas for service: ApiService

ReplicaRole   : Primary
NodeName      : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready

检查每个服务的副本状态是否为“就绪”。

检查网络控制器与每个 Hyper-V 主机之间的相应 HostID 和证书

在 Hyper-V 主机上,运行以下 cmdlet 以检查 HostID 与网络控制器上服务器资源的实例 ID 相对应

Get-ItemProperty "hklm:\system\currentcontrolset\services\nchostagent\parameters" -Name HostId |fl HostId

HostId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**

Get-NetworkControllerServer -ConnectionUri $uri |where { $_.InstanceId -eq "162cd2c8-08d4-4298-8cb4-10c2977e3cfe"}

Tags             :
ResourceRef      : /servers/4c4c4544-0056-4a10-8059-b8c04f395931
InstanceId       : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag             : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId       : 4c4c4544-0056-4a10-8059-b8c04f395931
Properties       : Microsoft.Windows.NetworkController.ServerProperties

修复

如果使用 SDNExpress 脚本或手动部署,请更新注册表中的 HostId 键以匹配服务器资源的实例 ID。 在 Hyper-V 主机上重启网络控制器主机代理 (物理服务器) 如果使用 VMM,请从 VMM 中删除 Hyper-V 服务器并删除 HostId 注册表项。 然后,再次通过 VMM 添加服务器。

检查 Hyper-V 主机使用的 X.509 证书的指纹 (主机名是否为证书的使用者名称) , (SouthBound) Hyper-V 主机 (NC 主机代理服务) 与网络控制器节点之间的通信相同。 还检查网络控制器的 REST 证书的使用者名称CN=<FQDN or IP>为 。

# On Hyper-V Host
dir cert:\\localmachine\my

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
...

dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**

# On Network Controller Node VM
dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**
...

还可以检查每个证书的以下参数,以确保使用者名称 (主机名或 NC REST FQDN 或 IP) 的预期名称,证书尚未过期,并且证书链中的所有证书颁发机构都包含在受信任的根颁发机构中。

  • 主题名称
  • 过期日期
  • 受根颁发机构信任

如果 Hyper-V 主机上的多个证书具有相同的使用者名称,则网络控制器主机代理将随机选择一个证书来呈现给网络控制器。 这可能与网络控制器已知的服务器资源的指纹不匹配。 在这种情况下,删除 Hyper-V 主机上具有相同使用者名称的证书之一,然后重启网络控制器主机代理服务。 如果仍无法建立连接,请删除 Hyper-V 主机上具有相同使用者名称的其他证书,并在 VMM 中删除相应的服务器资源。 然后,在 VMM 中重新创建服务器资源,这将生成新的 X.509 证书并将其安装在 Hyper-V 主机上。

检查 SLB 配置状态

SLB 配置状态可以作为 cmdlet 输出 Debug-NetworkController 的一部分确定。 此 cmdlet 还将输出 JSON 文件中的当前网络控制器资源集、每个 Hyper-V 主机的所有 IP 配置 (服务器) 主机代理数据库表和本地网络策略。

默认情况下,将收集更多跟踪。 若要不收集跟踪,请添加 -IncludeTraces:$false 参数。

Debug-NetworkController -NetworkController <FQDN or IP> [-Credential <PS Credential>] [-IncludeTraces:$false]

# Don't collect traces
$cred = Get-Credential
Debug-NetworkController -NetworkController 10.127.132.211 -Credential $cred -IncludeTraces:$false

Transcript started, output file is C:\NCDiagnostics.log
Collecting Diagnostics data from NC Nodes

注意

默认输出位置将是 <working_directory>\NCDiagnostics\ 目录。 可以使用 参数更改 -OutputDirectory 默认输出目录。

可以在此目录中的 诊断-slbstateResults.Json 文件中找到 SLB 配置状态信息。

此 JSON 文件可细分为以下部分:

  • 织物
    • SlbmVips - 本部分列出了 SLB 管理器 VIP 地址的 IP 地址,网络控制器使用它来协调 SLB 复用复用器与 SLB 主机代理之间的配置和运行状况。
    • MuxState - 本部分将为部署的每个 SLB 复用器列出一个值,并给出复用器的状态
    • 路由器配置 - 本部分将列出上游路由器 (BGP 对等) 自治系统编号 (ASN) 、传输 IP 地址和 ID。 它还将列出 SLB 复用 ASN 和传输 IP。
    • 连接的主机信息 - 本部分将列出所有可用于运行负载均衡工作负荷的 Hyper-V 主机的管理 IP 地址。
    • Vip 范围 - 此部分将列出公共和专用 VIP IP 池范围。 SLBM VIP 将作为其中一个范围分配的 IP 包含在内。
    • 复用路由 - 本部分将列出部署的每个 SLB 复用器(包含该特定复用的所有路由播发)的一个值。
  • Tenant
    • VipConsolidatedState - 本部分将列出每个租户 VIP 的连接状态,包括播发的路由前缀、Hyper-V 主机和 DIP 终结点。

注意

可以使用 Microsoft SDN GitHub 存储库上提供的 DumpSlbRestState 脚本直接确定 SLB 状态。

网关验证

从网络控制器:

Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface

从网关 VM:

Ipconfig /allcompartments /all
Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation

从机架顶部 (ToR) 开关:

sh ip bgp summary (for 3rd party BGP Routers)

Windows BGP 路由器:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

除此之外,从到目前为止我们看到的问题 (特别是基于 SDNExpress 的部署) ,未在 GW VM 上配置租户隔离舱的最常见原因似乎是,与人们尝试在 TenantConfig.psd1 中分配给网络Connections (S2S 隧道) 相比,FabricConfig.psd1 中的 GW 容量更少。 通过比较以下 cmdlet 的输出,可以轻松检查这一点:

PS > (Get-NetworkControllerGatewayPool -ConnectionUri $uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").property

[Hoster]验证 Data-Plane

部署网络控制器、创建租户虚拟网络和子网,并将 VM 附加到虚拟子网后,宿主可以执行其他构造级别测试,以检查租户连接。

检查 HNV 提供程序逻辑网络连接

在 Hyper-V 主机上运行的第一个来宾 VM 连接到租户虚拟网络后,网络控制器会将两个 HNV 提供程序 IP 地址 (PA IP 地址) 分配给 Hyper-V 主机。 这些 IP 将来自 HNV 提供程序逻辑网络的 IP 池,并由网络控制器管理。 若要了解这两个 HNV IP 地址,

PS > Get-ProviderAddress

# Sample Output
ProviderAddress : 10.10.182.66
MAC Address     : 40-1D-D8-B7-1C-04
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

ProviderAddress : 10.10.182.67
MAC Address     : 40-1D-D8-B7-1C-05
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

这些 HNV 提供程序 IP 地址 (PA IP) 分配给在单独的 TCPIP 网络隔离舱中创建的以太网适配器,并且具有 VLANX 的适配器名称,其中 X 是分配给 HNV 提供程序的 VLAN, (传输) 逻辑网络。

使用 HNV 提供程序逻辑网络的两个 Hyper-V 主机之间的连接可以通过 ping 和附加的隔离舱 (-c Y) 参数来完成,其中 Y 是在其中创建 PAhostVNIC 的 TCPIP 网络隔离区。 可以通过执行以下方法来确定此隔离舱:

C:\> ipconfig /allcompartments /all

<snip> ...
==============================================================================
Network Information for *Compartment 3*
==============================================================================
   Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-04
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::5937:a365:d135:2899%39(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.66(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-05
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::28b3:1ab1:d9d9:19ec%44(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.67(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

*Ethernet adapter vEthernet (PAhostVNic):*
<snip> ...

注意

PA 主机 vNIC 适配器不在数据路径中使用,因此没有分配给“vEthernet (PAhostVNic) 适配器”的 IP。

例如,假设 Hyper-V 主机 1 和 2 具有 HNV 提供程序 (PA) IP 地址:

Hyper-V 主机 PA IP 地址 1 PA IP 地址 2
主机 1 10.10.182.64 10.10.182.65
主机 2 10.10.182.66 10.10.182.67

可以使用以下命令在两者之间执行 ping 操作,以检查 HNV 提供程序的逻辑网络连接。

# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.64

# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.64

# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.65

# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.65

修复

如果 HNV 提供程序 ping 不起作用,检查物理网络连接,包括 VLAN 配置。 每个 Hyper-V 主机上的物理 NIC 应处于中继模式,没有分配特定的 VLAN。 管理主机 vNIC 应与管理逻辑网络的 VLAN 隔离。

PS C:\> Get-NetAdapter "Ethernet 4" |fl

Name                       : Ethernet 4
InterfaceDescription       : <NIC> Ethernet Adapter
InterfaceIndex             : 2
MacAddress                 : F4-52-14-55-BC-21
MediaType                  : 802.3
PhysicalMediaType          : 802.3
InterfaceOperationalStatus : Up
AdminStatus                : Up
LinkSpeed(Gbps)            : 10
MediaConnectionState       : Connected
ConnectorPresent           : True
*VlanID                     : 0*
DriverInformation          : Driver Date 2016-08-28 Version 5.25.12665.0 NDIS 6.60

# VMM uses the older PowerShell cmdlet <Verb>-VMNetworkAdapterVlan to set VLAN isolation
PS C:\> Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName <Mgmt>

VMName VMNetworkAdapterName Mode     VlanList
------ -------------------- ----     --------
<snip> ...
       Mgmt                 Access   7
<snip> ...

# SDNExpress deployments use the newer PowerShell cmdlet <Verb>-VMNetworkAdapterIsolation to set VLAN isolation
PS C:\> Get-VMNetworkAdapterIsolation -ManagementOS

<snip> ...

IsolationMode        : Vlan
AllowUntaggedTraffic : False
DefaultIsolationID   : 7
MultiTenantStack     : Off
ParentAdapter        : VMInternalNetworkAdapter, Name = 'Mgmt'
IsTemplate           : True
CimSession           : CimSession: .
ComputerName         : SA18N30-2
IsDeleted            : False

<snip> ...

检查 HNV 提供程序逻辑网络上的 MTU 和巨型帧支持

HNV 提供程序逻辑网络的另一个常见问题是,物理网络端口和/或以太网卡没有配置足够大的 MTU 来处理 VXLAN (或 NVGRE) 封装的开销。

注意

某些以太网卡和驱动程序支持新的*EncapOverhead关键字 (keyword) 网络控制器主机代理会自动将其设置为值 160。 然后,此值将添加到 *JumboPacket 关键字 (keyword) 的值,其求和用作播发的 MTU。

例如, *EncapOverhead = 160 和 *JumboPacket = 1514 => MTU = 1674B

# Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings

Verifying Physical Nic : <NIC> Ethernet Adapter #2
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Verifying Physical Nic : <NIC> Ethernet Adapter
Physical Nic  <NIC> Ethernet Adapter can support SDN traffic. Encapoverhead value set on the nic is  160

若要测试 HNV 提供程序逻辑网络是否支持更大的 MTU 大小的端到端,请使用 Test-LogicalNetworkSupportsJumboPacket cmdlet:

# Get credentials for both source host and destination host (or use the same credential if in the same domain)
$sourcehostcred = Get-Credential
$desthostcred = Get-Credential

# Use the Management IP Address or FQDN of the Source and Destination Hyper-V hosts
Test-LogicalNetworkSupportsJumboPacket -SourceHost sa18n30-2 -DestinationHost sa18n30-3 -SourceHostCreds $sourcehostcred -DestinationHostCreds $desthostcred

# Failure Results
SourceCompartment : 3
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1632
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1472
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.

修复

  • 将物理交换机端口上的 MTU 大小调整为至少 1674B (包括 14B 以太网标头和尾部)
  • 如果 NIC 卡不支持 EncapOverhead 关键字 (keyword) ,请将 JumboPacket 关键字 (keyword) 调整为至少 1674B

检查租户 VM NIC 连接

分配给来宾 VM 的每个 VM NIC 在专用客户地址 (CA) 与 HNV 提供程序地址 (PA) 空间之间具有 CA-PA 映射。 这些映射保存在每个 Hyper-V 主机上的 OVSDB 服务器表中,可以通过执行以下 cmdlet 找到。

# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping

CA IP Address CA MAC Address    Virtual Subnet ID PA IP Address
------------- --------------    ----------------- -------------
10.254.254.2  00-1D-D8-B7-1C-43              4115 10.10.182.67
10.254.254.3  00-1D-D8-B7-1C-43              4115 10.10.182.67
192.168.1.5   00-1D-D8-B7-1C-07              4114 10.10.182.65
10.254.254.1  40-1D-D8-B7-1C-06              4115 10.10.182.66
192.168.1.1   40-1D-D8-B7-1C-06              4114 10.10.182.66
192.168.1.4   00-1D-D8-B7-1C-05              4114 10.10.182.66

注意

如果预期的 CA-PA 映射不是给定租户 VM 的输出,请使用 cmdlet 在网络控制器Get-NetworkControllerNetworkInterface上检查 VM NIC 和 IP 配置资源。 此外,检查 NC 主机代理和网络控制器节点之间建立的连接。

有了此信息,托管商现在可以使用 cmdlet 从网络控制器 Test-VirtualNetworkConnection 启动租户 VM ping。

特定故障排除方案

以下部分提供了对特定方案进行故障排除的指南。

两个租户虚拟机之间没有网络连接

  1. [租户]确保租户虚拟机中的 Windows 防火墙未阻止流量。
  2. [租户]通过运行 ipconfig检查是否已将 IP 地址分配给租户虚拟机。
  3. [Hoster]从 Hyper-V 主机运行 Test-VirtualNetworkConnection 以验证相关两个租户虚拟机之间的连接。

注意

VSID 是指虚拟子网 ID。 对于 VXLAN,这是 VXLAN 网络标识符 (VNI) 。 可以通过运行 Get-PACAMapping cmdlet 找到此值。

示例

$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)

在主机“sa18n30-2.sa18.nttest.microsoft.com”上的 SenderCA IP 为 192.168.1.4 的“Green Web VM 1”之间创建 CA ping,Mgmt IP 为 10.127.132.153,侦听器CA IP 为 192.168.1.5,这些 IP 附加到虚拟子网 (VSID) 4114。

Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-2.sa18.nttest.microsoft.com -MgmtIp 10.127.132.153 -Creds $cred -VMName "Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP 192.168.1.4 -SenderVSID 4114 -ListenerCAIP 192.168.1.5 -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1

Starting CA-space ping test
Starting trace session
Ping to 192.168.1.5 succeeded from address 192.168.1.4
Rtt = 0 ms

CA Routing Information:

    Local IP: 192.168.1.4
    Local VSID: 4114
    Remote IP: 192.168.1.5
    Remote VSID: 4114
    Distributed Router Local IP: 192.168.1.1
    Distributed Router Local MAC: 40-1D-D8-B7-1C-06
    Local CA MAC: 00-1D-D8-B7-1C-05
    Remote CA MAC: 00-1D-D8-B7-1C-07
    Next Hop CA MAC Address: 00-1D-D8-B7-1C-07

PA Routing Information:

    Local PA IP: 10.10.182.66
    Remote PA IP: 10.10.182.65

 <snip> ...

[租户]检查虚拟子网或 VM 网络接口上是否指定了阻止流量的分布式防火墙策略。

在 sa18.nttest.microsoft.com 域的 sa18n30nc 的演示环境中查询网络控制器 REST API。

$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri

查看引用此 ACL 的 IP 配置和虚拟子网

  1. [Hoster]在托管有问题的两个租户虚拟机的两个 Hyper-V 主机上运行 Get-ProviderAddress ,然后运行 Test-LogicalNetworkConnectionping -c <compartment> 从 Hyper-V 主机运行,以验证 HNV 提供程序逻辑网络上的连接
  2. [Hoster]确保 Hyper-V 主机和 Hyper-V 主机之间的任何第 2 层切换设备上的 MTU 设置正确。 在所有有问题的 Hyper-V 主机上运行 Test-EncapOverheadValue 。 此外,检查,在两者之间切换的所有第 2 层将 MTU 设置为至少 1674 字节,以考虑最大开销 160 字节。
  3. [Hoster]如果 PA IP 地址不存在且/或 CA 连接中断,检查以确保已收到网络策略。 运行 Get-PACAMapping 以查看是否正确建立了创建覆盖虚拟网络所需的封装规则和 CA-PA 映射。
  4. [Hoster]检查网络控制器主机代理是否已连接到网络控制器。 为此,请运行 netstat -anp tcp |findstr 6640
  5. [Hoster]检查 HKLM/ 中的主机 ID 是否与托管租户虚拟机的服务器资源的实例 ID 匹配。
  6. [Hoster]检查端口配置文件 ID 是否与租户虚拟机的 VM 网络接口的实例 ID 匹配。

日志记录、跟踪和高级诊断

以下部分提供有关高级诊断、日志记录和跟踪的信息。

网络控制器集中日志记录

网络控制器可以自动收集调试器日志并将其存储在集中位置。 首次部署网络控制器时或以后随时可以启用日志收集。 日志从网络控制器和网络控制器管理的网络元素收集:主机、软件负载均衡器 (SLB) 和网关计算机。

这些日志包括网络控制器群集、网络控制器应用程序、网关日志、SLB、虚拟网络和分布式防火墙的调试日志。 每当将新的主机/SLB/网关添加到网络控制器时,会在这些计算机上启动日志记录。 同样,从网络控制器中删除主机/SLB/网关时,会在这些计算机上停止日志记录。

启用日志记录

使用 cmdlet 安装网络控制器群集时, Install-NetworkControllerCluster 会自动启用日志记录。 默认情况下,日志在 %systemdrive%\SDNDiagnostics 的网络控制器节点上本地收集。 建议将此位置更改为远程文件共享, (不是本地) 。

网络控制器群集日志存储在 %programData%\Windows Fabric\log\Traces。 可以使用 参数指定日志收集的集中位置, DiagnosticLogLocation 并建议这也是远程文件共享。

如果要限制对此位置的访问,可以使用 参数提供访问凭据 LogLocationCredential 。 如果提供用于访问日志位置的凭据,则还应提供 CredentialEncryptionCertificate 参数,该参数用于加密本地存储在网络控制器节点上的凭据。

使用默认设置时,建议在中心位置至少有 75 GB 的可用空间,如果三节点网络控制器群集不使用中心位置) ,则本地节点上至少有 25 GB 的可用空间 (。

更改日志记录设置

可以随时使用 Set-NetworkControllerDiagnostic cmdlet 更改日志记录设置。 可以更改以下设置:

  • 集中式日志位置。

    可以使用 参数更改位置以存储所有日志 DiagnosticLogLocation

  • 用于访问日志位置的凭据。

    可以使用 参数更改凭据以访问日志位置 LogLocationCredential

  • 移动到本地日志记录。

    如果已提供集中位置来存储日志,则可以使用参数 (不建议在网络控制器节点上 UseLocalLogLocation 本地进行日志记录,因为) 磁盘空间要求较大。

  • 日志记录范围。

    默认情况下,会收集所有日志。 可以更改范围以仅收集网络控制器群集日志。

  • 日志记录级别。

    默认日志记录级别为 Informational。 可以将其更改为“错误”、“警告”或“详细”。

  • 日志老化时间。

    日志以循环方式存储。 无论使用本地日志记录还是集中式日志记录,默认情况下都有三天的日志记录数据。 可以使用 参数更改此时间限制 LogTimeLimitInDays

  • 日志老化大小。

    默认情况下,如果使用集中式日志记录,则最多有 75 GB 的日志记录数据,如果使用本地日志记录,则最多有 25 GB 的日志记录数据。 可以使用 参数更改此限制 LogSizeLimitInMBs

收集日志和跟踪

默认情况下,VMM 部署对网络控制器使用集中式日志记录。 部署网络控制器服务模板时指定这些日志的文件共享位置。

如果未指定文件位置,则会在每个网络控制器节点上使用本地日志记录,日志保存在 C:\Windows\tracing\SDNDiagnostics 下。 这些日志是使用以下层次结构保存的:

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • 痕迹

网络控制器使用 (Azure) Service Fabric。 排查某些问题时,可能需要 Service Fabric 日志。 可以在 C:\ProgramData\Microsoft\Service Fabric 的每个网络控制器节点上找到这些日志。

如果用户运行了 cmdlet Debug-NetworkController ,则每个 Hyper-V 主机上将有更多日志可用,该主机已在网络控制器中使用服务器资源指定。 如果启用) ,这些日志 (和跟踪保存在 C:\NCDiagnostics 下

SLB 诊断

托管服务提供商操作) (SLBM 构造错误

  1. 检查软件负载均衡器管理器 (SLBM) 是否正常运行,以及业务流程层是否可以相互通信:SLBM -> SLB 复用和 SLBM -> SLB 主机代理。 从有权访问网络控制器 REST 终结点的任何节点运行 DumpSlbRestState
  2. 验证其中一个网络控制器节点 VM 上的 PerfMon 中的 SDNSLBMPerfCounters, (最好是主网络控制器节点 - Get-NetworkControllerReplica) :
    1. 负载均衡器 (LB) 引擎是否连接到 SLBM? (SLBM LBEngine 配置总计 > 0)
    2. SLBM 是否至少知道自己的终结点? (VIP 终结点总数>= 2)
    3. Hyper-V (DIP) 主机是否连接到 SLBM? (连接的 HP 客户端 == num 服务器)
    4. SLBM 是否连接到复用? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VM) 。
  3. 确保配置的 BGP 路由器已成功与 SLB MUX 对等互连。
    1. 如果将 RRAS 与远程访问 (,则 BGP 虚拟机) :
      1. Get-BgpPeer 应显示已连接。
      2. Get-BgpRouteInformation 应至少显示 SLBM 自 VIP 的路由。
    2. 如果使用物理架顶 (ToR) 切换为 BGP 对等互连,请参阅文档:
      1. 例如:# show bgp instance
  4. 在 SLB 复用 VM 上的 PerfMon 中验证 SlbMuxPerfCounters 和 SLBMUX 计数器。
  5. 检查软件负载均衡器管理器资源中的配置状态和 VIP 范围。
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (检查 IP 池中的 VIP 范围,并确保 SLBM 自 VIP (LoadBalanacerManagerIPAddress) 并且任何面向租户的 VIP 都在这些范围内)
      1. Get-NetworkControllerIpPool -NetworkId "<Public/Private VIP Logical Network Resource ID>" -SubnetId "<Public/Private VIP Logical Subnet Resource ID>" -ResourceId "\<IP Pool Resource Id>" -ConnectionUri $uri |convertto-json -depth 8
    2. Debug-NetworkControllerConfigurationState -

如果上述任何检查失败,租户 SLB 状态也将处于失败模式。

修复

根据提供的以下诊断信息,修复以下问题:

  • 确保已连接 SLB 多路复用器
    • 修复证书问题
    • 修复网络连接问题
  • 确保成功配置 BGP 对等互连信息
  • 确保注册表中的主机 ID 与服务器资源中的服务器实例 ID 匹配 (参考 HostNotConnected 的附录错误代码)
  • 收集日志

托管服务提供商和租户操作 (SLBM 租户错误)

  1. [Hoster]检查 Debug-NetworkControllerConfigurationState 是否有任何 LoadBalancer 资源处于错误状态。 尝试按照附录中的操作项表进行操作来缓解。
    1. 检查 VIP 终结点是否存在并播发路由。
    2. 检查为 VIP 终结点发现了多少 DIP 终结点。
  2. [租户]验证负载均衡器是否正确指定了资源。
    1. 验证在 SLBM 中注册的 DIP 终结点是否托管租户虚拟机,这些虚拟机对应于 LoadBalancer 后端地址池 IP 配置。
  3. [Hoster]如果未发现或连接 DIP 终结点:
    1. 检查 Debug-NetworkControllerConfigurationState

      使用 验证 NC 和 SLB 主机代理是否已成功连接到网络控制器事件协调器 netstat -anp tcp |findstr 6640)

    2. 在附录) 中签 HostIdnchostagent 服务 regkey (引用 HostNotConnected 错误代码与相应服务器资源的实例 ID (Get-NCServer |convertto-json -depth 8) 匹配。

    3. 检查虚拟机端口的端口配置文件 ID 是否与相应的虚拟机 NIC 资源的实例 ID 匹配。

  4. [托管提供商]收集日志。

SLB 复用器跟踪

软件负载均衡器复用工具中的信息也可以通过事件查看器确定。

  1. 选择“事件查看器视图”菜单下的“显示分析和调试日志”。
  2. 导航到 事件查看器 中的应用程序和服务日志>Microsoft>Windows>SlbMuxDriver>跟踪
  3. 右键单击它并选择“ 启用日志”。

注意

建议在尝试重现问题时,仅在短时间内启用此日志记录。

VFP 和 vSwitch 跟踪

从托管附加到租户虚拟网络的来宾 VM 的任何 Hyper-V 主机中,可以收集 VFP 跟踪以确定问题可能出在哪里。

netsh trace start provider=Microsoft-Windows-Hyper-V-VfpExt overwrite=yes tracefile=vfp.etl report=disable provider=Microsoft-Windows-Hyper-V-VmSwitch
netsh trace stop
netsh trace convert .\vfp.etl ov=yes